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RELATED APPLICATION 
This application claims priority from a provisional application filed December 1 1, 
1995, entitled "A WORLD WIDE WEB REGISTRATION INFORMATION 
PROCESSING SYSTEM" and assigned provisional Serial No. 60/008,736. 

FIELD OF THE INVENTION 
The present invention relates to a system for assisting World Wide Web users in 
registering at World Wide Web web sites. In particular, the present invention provides 
storage and access to web site registration information provided by a user of the present 
invention so that, upon requesting to register at a web site that cooperates with the present 
invention, the user can request his/her web site registration information stored by the 
present invention to be transmitted to the cooperating web site. 

BACKGROUND OF THE INVENTION 
The World Wide Web (WWW) is a global communications neta'ork having a 
client-server model as a paradigm for commimications. That is, users on client nodes 
utilizing so called "web browsers" navigate the WWW to access desired server nodes 
(known as web sites) for at least obtaining information from the server nodes such as 
hypertext, audio, video, virtual reality, data, etc. For many web sites, it is important to 
those responsible for the design and maintenance of the web sites that they be capable of 
accurately measuring both the niunber and types of users accessing their web sites. In 
particular, such measurements may be important in determining fees that can be charged 
by web site developers for building and maintaining a web site. Further, such 



information may be useM in detennining the degree of interest in services and products 
by web site users. Thus, in order to obtain these web site measurements, such web sites 
have begun requesting that each user provide information about himselfiTierself prior to 
the web site allowing access to web site services. That is, such web sites require a user 
to "register" at the web site, wherein the user is required to establish a user identification 
(user ID) and optionally a password with the web site as well as typically provide 
personal information such as, for example, the city of residence or family size. However, 
registering at multiple web sites is burdensome for users in that it is: (a) time consuming, 
and (b) the user is likely to have different user IDs at different web sites, thus requiring 
a user to maintain a list of user IDs (and optionally passwords) for the web sites to which 
he/she is registered. 

Therefore, it would be advantageous to alleviate many of the above difficulties 
by automating the registi^tion process at web sites so that users may register at a single 
web site and use the information provided at this web site to more easily register at other 
web sites. 

SUMMARY OF THE INVENTION 
The present invention is a registration information processing system for the 
World Wide Web that substantially automates the user registiration process at web sites. 
The registration system of tiie present invention includes a World Wide Web registration 
web site wherein a user accessing tiie World Wide Web can utiUze tiiis web site as a 
repository for registration information so that the user can request tiiis registration 
information to be transmitted substantially automatically to another web site to which the 
user desires to register. Furthermore, the present invention provides the user with a 



common user ID, and optionally common password, that can be used to access a plurality 
of web sites so that there are fewer web site user IDs and passwords for the user to 
remember. Additionally, the present invention may establish the common user ID (and 
optionally password) through user input such that the user may request a candidate user 
ID (and optionally password) and, if acceptable, the candidate user ID becomes the 
common user ED. However, if the candidate user ED is unacceptable (e.g., because it is 
a duplicate of another user's common user ED), then the present invention provides the 
user with one or more altematives for the common user ID (and optionally password) that 
the user may accept or reject. Further, note that whenever possible the present invention 
provides the user with alternative common user IDs wherein the altematives are derived 
from the candidate user ID provided by the xiser. 

The registration information processing system of the present invention has a first 
embodiment using a first system architecture wherein a user need not have any modules 
specific to the present invention loaded on his/her World Wide Web client node. In this 
embodiment, once the user has provided registration information to the registration web 
site of the present invention, when the user subsequently requests to register at a new web 
site cooperating with the registiration process of the present invention, 4hen the user 
provides this new web site with a xiser ID and optionally password (e.g., the above- 
mentioned common user ID) for the registration web site of the present invention together 
with an indication that any further information may be obtained fi-om the registration web 
site. The new web site subsequently is able to automatically retrieve tiie user's 
registi^tion information firom the registration web site and register the user at the new 
web site. 



In a second embodiment of the present invention having a second architecture, 
World Wide Web client nodes have registration modules for the present invention loaded 
on them so that these nodes may interact with the registration web site for providing user 
registration information to cooperating web sites to which the user requests to register. 
In this second embodiment of the present invention, the user's registration information 
is stored both locally on the usef s client node and at the registration web site, the web site 
being used as a backup. Thus, when the user desires to register at a new web site, the 
user's registration information is provided to the web site from the registration module 
residing on the user's client node. 

In either embodiment, the present invention may also provide a "mass" 
registration capability, wherem a user may request that the present invention 
automatically register the user at a plurality of web sites. For example, the user may be 
provided with a capability to search for web sites cooperating with the present invention 
by, for example, category and request an automatic registration at multiple web sites 
substantially simultaneously. 

Other features and benefits of the present invention will become apparent from 
the detailed description with the accompanying figures contained hereinafter. 

BRIEF DESCRIPTION OF THE DRAWINGS 
Fig. 1 is a block diagram of the web site registration information processing 

system of the present invention, wherein this system is shown m the context of its 

connections to various nodes of the World Wide Web; 

Figs. 2A and 2B provide a flowchart for describing the steps performed when a 

USCT of the World Wide Web explicitly contacts the registrar web site 100 of the present 



invention for supplying registration information to be xised in registering at third party 
web sites 116; 

Fig. 3 is a flowchart presenting the steps a user of the World Wide Web performs 
when entering web site registration information into fill-out forms that are to be 
submitted to the registrar web site 100 of the present invention; 

Figs. 4A and 4B present a flowchart for the steps performed when a user of the 
World Wide Web accesses a third party web site 116, cooperating with the present 
invention, and in the process of registering at the third party web site the user is 
automatically put in contact with the registrar web site 100 of the present invention so 
that registration information may be provided to the present invention for registering the 
user at the present third party web site as well as other third party web sites that the user 
may subsequently request; 

Fig. 5 is a flowchart of the steps performed by the present invention when 
transferring usar registration information fix»m the registrar web site 100 to a third party 
web site 1 16 to which the tiser has requested to register. 

Figs. 6 A and 6B provide a flowchart of the steps performed when supplying a 
third party web site 116 with registration information from the registrar web site 100, 
assuming that the third party web site has requested such information and that the request 
has been authenticated at the registrar web site 100; 

Fig. 7 presents a flowchart of the st^s pCTformed by the present invention when 
suppl3dng a third party web site 116 with user registration information from the user 
registration information database 144; 



Fig. 8 presents a flowchart of the steps performed when storing in the user 
registration information database 144 a user's ID (and optionally password) relating to a 
third party web site 1 16 to which the user is registered via using the present invention; 

Fig. 9 is a flowchart of the steps performed when registering at a third party web 
5 site 116 using the module 156 of the present invention installed on the user's client node 
108; 

Fig. 10 is a flowchart of the steps performed when the registration module 156 
on the user's client node is utilized in supplying a third party web site 116 with 
registration information; 
1 0 Figs. 1 1 A and 1 1 B presmt a flowchart of the stq>s performed when a World Wide 

Web user of the present invention changes his/her registration ioformation stored in the 
present invention; 

Figs. 12A and 12B present a flowchart of the steps performed when the 
architecture of the present invaition includes the registration module 156 provided at the 
15 user's client node 108 and the user requests to enter registration information into the 
present invention using this module; and 

Figs. 13A and 13B provide a flowchart of the stq)s performed When a World 
Wide Web user requests a user ID for the registration information processing system of 
the present invention and the present invention includes module 1 56 on the user's client 
20 node 108. 

DETAILED DESCRIPTION 
Fig. 1 is a block diagram of a web site registration information processing system 
of the presCT.t invention, (hereinafter also denoted by the name "registrar") wherein this 
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system is shown in the context of its connections to various nodes of the World Wide 
Web (WWW). In a first embodiment, a web site, denoted the registrar web site 100, 
provided by the present invention, is connected to the World Wide Web 104 for 
communicating with both World Wide Web cUent nodes such as WWW client node 1 08, 
5 and with other web sites such as third party web site 116, wherein the registrar web site 
100 facilitates the registration of a user at a WWW chent node 108 when this user desires 
to register at the third party web site 1 16. In this first embodiment, the user accesses the 
World Wide Web 104 through a WWW browser 120 on a WWW client node 108 
wherein, to use the registration facilities of the registrar web site 100 for registering the 
1 0 user at a one or more third party web sites 116, the user must in some manner request 
exphcit access to the registrar web site 100 for registering Insfher registration information 
to the registrar web site 100. Additionally, in this first embodiment of the present 
invention, the WWW client node 108 need not have executable program modules 
designed specifically for interfacing with the registrar web site 100. That is, substantially 
15 any conventional World Wide Web browser may be used as the WWW browser 120. 

Thus, the first embodiment of the present invention may be described as follows. 
In order for a user to register at one or more third party web sites 1 16, the user at a WWW 
client node 108 accesses the World Wide Web 104 and in a first scaiario explicitly 
navigates through the World Wide Web 104 to the registrar web site 100 wherein a 
2 0 registrar web site 1 00 home page is communicated back to the user's WWW browser 1 20. 
As one skilled in the art will appreciate, program modules 128 (hereinafter denoted 
"registrar applications") output, to a World Wide Web network server 132, information 
in, for example, a hypertext markup language (HTML) related to capabilities of the 
registrar web site 100 in assisting the user in registering at third party web sites 116. 



Such outputs from registrar applications 128, are subsequently transmitted, via the 
network server 132 and the network interface 136, to the user's WWW browser 120 in 
the hypertext transfer protocol (HTTP), as one skilled in the art will appreciate. Thus, 
upon presentation of the registrar web site 100 home page on the user's WWW client 
node 108, the user subsequently may request to provide registration information to the 
registrar web site 100 so that he/she can have this information at the registrar web site 
100 automatically transferred to a third party web site 116 when the user is requested to 
register at such a third party web site. Subsequently, after the user's request to supply 
registration information is transmitted to the registrar web site 100 (via World Wide Web 
104, network interface 136 and network servo: 132), the registrar applications 128 receive 
the request and output to the user's WWW browser 120 one or more "web pages" having 
fill-out forms to be presented to the user via the WWW browser 120. Thus, upon 
submittal of the filled out forms by the user to the registrar web site 100 (more precisely, 
the registrar appUcations 128), the user's registration information is stored in the user 
registration information database 144. 

Following the above registration procedure at the registrar web site 100, the user 
may then substantially automatically register at various third party web sites 1 16 that are 
affiliated with the registrar web site 100 in that an agreement has been reached between 
each such third party web site 116 and the registrar web site 120 for transmitting a user's 
registration information to the third party web site 1 16 when, for example, the user 
requests such transmittal. Thus, assuming the user accesses the third party web site 116 
and, for example, the home page for the third party web site 116 includes a form field 
allowing the user to specify that the user's registration information is stored and 
accessible at the registrar web site 100, then the user can submit a response, via the 



World Wide Web 104, to the third party web site 116 indicating that the user's 
registration information should be obtained from the registrar web site 100. Thus, the 
third party web site 116 requests and receives the usef s registration information from the 
registrar web site 100 and stores the user's registration information in registration 
information database 148 directly accessible by the third party web site 116. Additionally 
note that when the registrar web site 100 receives a request from the third party web site 
1 16 for user registration information, a registrar application 128 records the request for 
the user's registration information in a registrar access log data base 152. Thus, the 
registrar web site 100 maintains a log of the third party web sites requesting registration 
information. Further, such third party web sites 116 may periodically provide the 
registrar web site 100 with information related to the frequency that users registered at 
the registrar web site 100 have accessed the third party web sites 116. Therefore, by also 
storing this information, for example, in the registrar access log 152, the registrar web site 
100 is able to determine the frequency and type of access of third party web sites 1 16 by 
users. 

In a second method of using the first embodiment of the present invention, instead 
of the user exphcitly navigating the World Wide Web 104 to the registrar Veb site 100 
for providing registration information, the user may instead access a third party web site 
116 wherein the home page or \registration page for the third party web site includes 
input fields allowing the user to request that the registrar web site 100 automatically be 
accessed so tibat the user can enter web site registration information at the registrar web 
site 100 and subsequently use the registration information provided to the registrar web 
site 100 for automatically registering at the third party web site 1 16 (as well as other third 
party web sites that may be subsequently requested). That is, the newly entered 



registration information is transferred to the third party web site 1 16 by entering into a 
registrar specific portion of the registration form for the third party web site 116 a 
registrar user identification and optionally a password for requesting that the third party 
web site access the registrar web site 100 to obtain the user's registration information. 
5 Thus, the user's registration information automatically is communicated to the third party 
web site 116 without the user explicitly having to navigate the World Wide Web 104 and 
access the registrar web site 100 to register his/her web site registration information. 

Note that alternative embodiments are within the scope of the present invention, 
wherein program modules for the present invention are distributed so that there is an 

1 0 executable module provided on the user's WWW cUent node 1 08 for communication with 
the registrar web site 100 as well as with third party web sites 116 that accept registration 
information firom the present invention. In one embodiment of such a distributed 
architecture for the present invention, a registrar registration module 156 is integrated 
into the user's WWW browser 120 for gathering the user's web site registration 

15 information and communicating with the registrar web site 100 as well as cooperating 
third party web sites 1 16 at which the user desires to registar. Such a registration module 
156 may provide the user with easier access to his/lier registration information since the 
information resides locally on the user's WWW client node 108 in a persistent nonvolatile 
storage. Further, the registrar registration module 156 may be activated for entering or 

2 0 updating user registration information without the user necessarily being connected to the 
World Wide Web 104. Moreover, by integrating the registrar registration module 156 
into the user's WWW browser 120, the user is presented with an integrated set of 
fiinctions for registering and accessing third party web sites 116. 
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Thus, in such distributed architectures, after the user has entered registration 
information into the registrar registration module 156, this module will substantially 
automatically contact the registrar web site 100 (via the World Wide Web 104) and 
thereby communicate the user's registration information to the registrar web site 100 so 
5 that, for example, the user's registration information may be reliably stored in case there 
are failures at the user's WWW client node 108. Thus, to access a third party web site 
116 that cooperates with the registrar for registering the user, once the user has made 
contact through the World Wide Web 104 with such a third party web site 116, the user 
transfers his/her registration information from the registration module 156 to the third 

1 0 party web site. Further note that in the registration process of the present embodiment, 
whenever the user registers at a third party web site 116, the registrar web site 100 is 
provided, by (for example) the module 156, with information related to the registration 
so that the user also has a off-site backup copy of all registrations at third party web sites 
residing at the registrar web site 100. 

15 Note that other distributed architectures for the present invention are also 

contemplated wherein the registrar registration module 156 on the user's WWW client 
node 108 is not integrated with the user's WWW browser 120. In such an embodiment, 
the user may be faced with a different user interaction technique for flie module 1 56 than 
that of the WWW browser 120. However, the user is provided with added flexibility in 

2 0 choosing a WWW browser 1 20 and/or using his/her existing browser 1 20 which may not 
contain as part of the browser the registrar registration module 1 56. 

In Figs. 2A and 2B, a flowchart is presented describing the steps performed when 
the user explicitly navigates the World Wide Web 104 to contact the registrar web site 
100 for supplying registration information. Accordingly, assummg the user contacts the 



registrar web site 100, in step 204 the web site 100 receives the user's request for 
information. Subsequently, in step 208 the registrar web site 100 responds with a home 
page describing the registrar services, a selection or browsing capability for reviewing 
third party web sites 116 accepting registrar registrations, and a fill-out form so that the 
user may request to proceed, if desired, with entering registration information at the 
registrar web site 100. In step 212 the user determines whether to proceed with the 
registration process or not. Assuming the user elects to proceed, the request to proceed 
is transferred back to the registrar web site 100 wherein a registrar application 128 
examines the response and outputs a fill-out form that is ti-ansmitted back to the user's 
WWW browser 1 20 so that the user may enter his/her registration information and submit 
it to the registrar web site 100. Thus, in step 216 the steps of the flowchart of Fig. 3 are 
performed by the user when entering information into the registration fill-out form 
provided by the registrar web site 100. Subsequently, in step 220 the user initiates the 
transfer of his/her registration information to the registrar web site 100. Note that the 
submittal of the registration information may be performed by a conventional electronic 
transfer through the World Wide Web 104 using any one of various intranet protocols or, 
alternatively, other techniques for transferring the information to the re^strar web site 
100 are also contemplated. For example, the user may fax a printed copy of a completed 
registration form to the registrar web site 100 at which point the information may be 
manually input into the user registration information database 144. In step 224, upon 
receiving the user's registration information, one or more registrar applications 128 
review the user's registration information for determining whether there is enough 
information supplied to at least uniquely identify the user. If not, then in steps 228 and 
232 a registrar application(s) 128 requests additional information firom the user and flags 
12 



the user's information currently stored in the user registration information database 144 
indicating that a user response is required to further process the user's information. As 
an aside, note that other feedback loops to the user are contemplated that are related to 
the loop of steps 224 through 232. For example, it may be the case that the user has 
5 supplied sufficient information to be imiquely identifiable at the registrar web site 100, 
but the user has supplied insufficient information for the registrar web site 100 to supply 
adequate information to most third party web sites 116 that utiUze registrar registration 
capabilities. Thus, a similar feedback loop to loop 224 through 232 may be provided for 
requesting that the user supply additional information so that a substantial number of 

1 0 third party web sites 116 cooperative with registrar will allow the user to register at them 
using only the information supplied by the registrar web site 100. 

Refeiring again to step 224, if a determination is made that sufficient registration 
information has been received at the registrar web site 100, the user's registration 
information is stored in the user registration information database 144 (step 236) and 

15 subsequently a registrar application 128 outputs a request to the user to select a user DD 
and password that can be at least used to access the user's registration information at the 
registrar web site 100 (step 240). Assuming, as in step 244, that the user submits a user 
ID and a password to the registrar web site 100, then in step 248 a determination is made 
by the present invention (more particularly, a registrar application 128) as to whether the 

2 0 user supplied ID and password is acceptable for uniquely identifying the user. If not, then 
steps 240 through 248 are rq)eated until an appropriate user JD and password are entered 
by the user. Thus, assuming that an acceptable user ID and password are provided, in 
step 252 the registration mfonnation supplied by the user is marked as unverified since 
there has been no independent confirmation that the user suppUed information is accurate. 



Subsequently, in step 256 a registrar application 128 commences to enrich the user's 
supplied registration information with publicly available information related to the user 
and, to the degree possible (i.e., conforming with internet etiquette, privacy concerns of 
users, and public poUcy), to verify the user's registration information. Note that by 
5 comparing the user supplied information with information about the user from other 
sources, a determination can be made as to the accuracy of the user suppUed information. 
Thus, whenever an item of the user supplied information is independently verified, then 
that item is immarked. Alternatively, if discrepancies arise between the user-supplied 
information and other publicly available information about the user, then the user may 

10 be alerted to these discrepancies and requested to confirm his/her initial responses. 

Referring now briefly to Fig. 3, this flowchart presents the steps a user performs 
when entering web site registration information into the fill-out forms to be submitted to 
registrar. Accordingly, in step 304 the user determines whether to supply basic 
information (i.e., requested by a substantial number of third party web sites 116) as 

1 5 described in step 308 or to supply expanded information (i.e., more extensive information 
about the user so that, for example, registrar has sufficient user information to register the 
user at substantially all cooperating third party web sites 1 16). Note that &t least in one 
embodiment, the basic infonnation supplied in step 308 (i.e., the user's name, e-mail 
address, gender and date of birth) is also requested in the forms for expanded infonnation 

20 in step 312. Thus, upon filling in at least one field from the fill-out forms (step 316) 
presented in either step 308 or 312 the present invention field checks the user's unput for 
syntactically appropriate responses. Subsequently, in step 320, the user inputs a request 
to terminate entering information in the presently presented fill-out fonn(s) and in step 
324 the user determines whether to enter additional information in either the basic 



registration information fill-out forms or the expanded information fill-out forms. If the 
user indicates that he/she desires to enter further registration information, then step 304 
is again performed. Alternatively, the- flowchart returns to the invoking program 
(flowchart) with the user supplied registration information. 

Figs. 4A and 4B present a flowchart for the steps performed when the user 
accesses a present third party web site 1 16 cooperating with registrar, and in the process 
of registering at the third party web site the user is automatically put in contact with the 
registrar web site 100 so that registration information may be provided to registrar for 
registering the user at the present third party web site as well as other third party web sites 
that the user may request. Accordingly, assuming the user uses a WWW browser 120 to 
access a third party web site 1 16 as in step 404, the third party web site responds with a 
web site home page (step 408) typically having a registration fill-out form into which the 
user is requested to enter registration information. Note that the user may or may not be 
registered at this third party web site. Thus, if tiie user is registered, then he/she may only 
need to enter a user ID and optionally a password in order to gain access to a desired 
application at the third party web site. Further note that for different tiiird party web sites 
116, the user's identification (and optionally a password) may be different due to 
constraints on user ID (and password) syntax being different at different third party web 
sites. Further, such user IDs at different web sites may be different because a user ID 
requested by the user may already have been assigned to another user. 

Subsequently, once the third party web site 116 has received a response firom the 
user, a determination is made as to whether the user is registered at the web site (step 
412). If the user is registered, then no fiirther processing related to the present invention 
is required. Alternatively, if the user is not registered at the third party web site, then a 
15 



response is transferred from the third party web site 116 through the World Wide Web 
104 to the usefs WWW browser 120 providing the user with the fill-out forms in which 
the user is requested to enter infonnation for registering at the third party web site. Note 
that if the third party web site 1 16 is configured to accept user registration infonnation 
5 from the present invention, then at least one fill-out form related to registering at the third 
party web site 116 will request infonnation related to registering the user by using the 
present invention. In particular, the third party web site 116 may present the user with 
a fill-out form requesting the user to enter a user ED and optionally a password for the 
present invention (i.e., registrar) if the user is registered at the registrar web site 100. 

1 0 Additionally, the presented fill-out forms may request the user to indicate whether he/she 
prefers to register at the third party web site 1 16 by using registrar. Thus, assuming the 
user desires to register at the third party web site 116, a determination is made as to 
whether the user wishes to register using the present invention or register at the third 
party web site witiiout using the present invaition (step 416). If the user chooses to not 

15 use the present invention for registering at the third party web site 116, then the user 
explicitly suppUes registration information for the present third party web site (step 420). 
Alternatively, if the user chooses to use registrar to register, then once the present third 
party web site 116 receives a response from the user indicating the choice to use registrar 
to register, in step 424, the present third party web site sends a request to the registrar 

2 0 web site 100 for regist^ing the user at the registrar web site 1 00. Subsequently, in step 
428 the steps of Figs. 2A and 2B are performed for registering the user at the registrar 
web site 100. Subsequently, after registering at the registrar web site 100, in step 432, 
the user is automatically placed in contact with the present third party web site so that 
he/she submits a registration fill-out form to this third party web site 1 16: (a) indicatmg 



that the user's registration information may be obtained from the registrar web site 100; 
and (b) providing a user ID (and optionally a password) for the registrar web site 100 to 
be used as IdentijBcation at the present third party web site. Following this, in step 436 
the third party web site 116 invokes the program corresponding to Fig. 5 to obtain the 
5 usef s registration data from the registrar web site 100. Lastly, upon verification by the 
third party web site 1 16 of the user's registration data, the user is granted access to the 
desired third party web site and/or application (step 440). 

In Fig. 5, a flowchart is presented of the registration data transmission process 
from the registrar web site 100 to a third party web site 116. Accordingly, in step 504 the 

1 0 third party web site 1 16 provides the re^strar web site 100 with identification of the third 
party web site, the user's registrar user ID and (any) registrar peissword. Further, in some 
instances, as will be described below, the third party web site 116 also supplies the 
registrar web site 100 with a return path to the user through the World Wide Web 104. 
Following this, in step 508, a determination is made by the registrar web site 100 as to 

1 5 whetiier the third party web site suppUed information can be authenticated If not all third 
party web site information is authenticated, then step 512 is encountered wherein a 
determination is made as to whether to request that the third party web sit6 to resend the 
information of step 504. Note that such a determination may be made in one embodiment 
depending upon whether the third party web site identification is authenticated. That is, 

20 if the third party web site identification is authenticated, then a retry may be allowed. 
Otherwise, no retry may be allowed. Alternatively, referring again to step 508, if all 
information transmitted from the third party web site 1 16 is authenticated at the registrar 
web site 100, then step 516 is encountered. In this step, flie program represented by Figs. 



17 



6 is performed for supplying the third party web site 116 with registration information 
related to the user from the user registration information database 144. 

Referring now to Figs. 6 A and 6B, the flowchart presented here provides the steps 
for supplying a present third party web site 116 with registration information from the 
5 registrar web site 100, assimiing that the present third party web site 116 has requested 
such information and that the request has been authenticated at the registrar web site 100. 
Accordingly, in step 604 the registrar web site 100 or, more precisely, a registrar 
application 128 performs the steps of Fig. 7 for retrieving the user registration 
information requested by the present third party web site 116 from the user registration 

10 information database 144. Note that a third party web site 116 may request various 
categories of information from the registrar web site 100 related to the user. In particular, 
a third party web site may request: (a) basic information as discussed in step 308 of Fig. 
3; (b) expanded information as discussed in step 312 of Fig. 3; (c) custom information, 
wherein selected fields from the basic and expanded information are provided; and (d) 

1 5 proprietary information wherein one or more additional user related information items 
may be provided wherein these items have been obtained by the registrar web site 1 00 by, 
for example, enriching and verifying the registration information obtmnedtSrom the user 
as in step 256 of Fig. 2B. 

Following step 604, step 608 is encountered wherein a registration application 

20 1 28 determines whether the present third party web site 116 requesting user information 
(for a user attempting to register at this third party web site) requires that a user ED (and 
optionally password) be goierated specifically for this third party web site. That is, the 
third party web site 116 may require a user ID and/or password that conforms with a 
format pecuUar to the third party web site 1 16. Note that to perform the step 608, in at 



least one embodiment of the present invention, infonnation related to the requirements 
of the present third party web site 116 are stored at the registrar web site 100. In 
particular, the registrar web site 100 may store a user infonnation request template for 
each third coordinating party web site 116 having access to user information at the 
5 registrar web site 100 such that a registrar application 128 (upon identifying a particular 
third party web site 1 16) may access a related user infonnation request template for 
determining what information may be required by this third party web site. 

If a user ID and optionally password need not be generated specifically for the 
requesting third party web site 116, then m step 61 2 the user information requested by the 

1 0 third party web site 1 1 6 is encrypted and in step 6 1 6 the encrypted information is sent to 
the third party web site. Following this, in step 620 a registrar z^pUcation 128 logs an 
entry or a record in the registrar access log database 152 indicating that registration 
information for the user has been transmitted to the present third party web site 116. 
Subsequently, in step 624 a registrar appUcation 128 (or, more precisely, an instantiation 

15 thereof) waits for an accqjtance response from the present third party web site 116 to 
which the encrypted user infonnation was sent. Note that the response from the present 
third party web site may include a third party web site specific user ID (^d optionally 
password) if the user was not previously registered at this third party web site. That is, 
the third party web site may automatically generate at least a user ID if the user was not 

2 0 previously registered at the web site. Alternatively, it may be the case that the present 
third party web site uses the user's registrar registration user ID and password for 
registering the user at the third party web site 1 16. Note that in at least one embodiment 
for registration processing at a third party web site 1 16, the use of the registrar viscr ID 
does not create ambiguity in the identity of users registering at the third party web site. 



For example, a user seeking access to a cooperating third party web site may be required 
to indicate that his/her user ID and/or password is a registrar generated user ID (and/or 
password) so that the third party web site can process the entered user identification 
differently from that of users who have registered without using the present invention. 
Subsequently, when an acceptance response from the requesting third party web site 1 1 6 
is provided to the regisfrar web site 100 (or, more precisely, a regisfrar application 128), 
this response is logged in the registrar access log database 152 in step 628. Following 
this latter step, in step 632, a determination is made as to whether the response from the 
present third party web site 116 indicates that the user is now registered at this third party 
web site. If no such indication is provided, then in step 636 a message is sent to the user 
at the user's WWW client node 108 that registrar cannot register the user at the present 
third party web site to which the user has requested registration and access. Further, the 
registrar appUcation 128 performing step 636 may also supply the user with a reason as 
to why the user cannot register through registrar at the present party web site if such a 
reason was indicated by this third party web site when the response of step 624 was 
received. 

Alternatively, if in step 632 it is determined that the user is registered at the 
present third party web site, flien in step 640 the program corresponding to the flowchart 
of Fig. 8 is performed for storing at least the user's ID (and optionally password) for the 
present third party web site at the registrar web site 100 (more precisely, in the user 
registration information database 144) as will be discussed hereinbelow. 

Referring again to step 608 of Fig. 6A, if a registrar ^plication 128 is required 
to generate a user ID (and optionally password) for the third party web site 116, then ste^ 
644 is next performed wherein a registrar application 128 generates a user ED (and 
20 



optionally password) to be transmitted to the third party web site 1 16. Subsequently, the 
sequence of steps 648 through 668 are performed. Note that this sequence of steps is 
substantially the same sequence of steps as steps 612 through 632. However, the 
response from the present third party web site logged in step 664 may include an 
indication as to whether the user generated by the registrar application 128 is acceptable 
to the present third party web site 116. 

Accordingly, continuing the discussion of Figs. 6 A and 6B from step 668, if the 
response from the present third party web site 116 indicates that the user is registered at 
the desired third party web site, then step 672 is performed wherein the program 
corresponding to the flowchart of Fig. 8 is again used to store the user's ID (and 
optionally password) for the present third party web site in the user registration 
information database 144 (as in step 640). Alternatively, if in step 668 it is determined 
that the user is not registered at the present third party web site 116, then in step 676 a 
determination is made as to whetber the gaierated user registration information (i.e., user 
ID and optionally password) step 644 has been rejected by the present third party web 
site. If so, then in step 680 a determination is made as to whether this rejection has 
occurred less than a predetermined number of times (i.e., the sequence of steps 644 
through 668 have been iteratively performed less than a predetermined number of times 
in attempting to register the user at the present third party web site). If the results of the 
test in step 680 is affirmative, then step 644 is again encountered for generating 
alternative user registration information for the present third party web site. Note that it 
is an aspect of the present invention that, at least in one embodiment, such generations 
produce user IDs tiiat are meaningftil to the user and/or are related to other web site 
registration user IDs for the user. Thus, in one embodiment of the present invention, the 



step 644 uses the xiser's registrar user ID as a "seed" from which to generate a user ID 
acceptable to the present third party web site 1 16. Moreover, note that the generation 
process of step 644 may use various heuristics and third party web site constraints to 
generate acceptable user IDs. 

Alternately, if the negative branch from step 676 is followed, then the third party 
web site 1 16 may have rejected registering the user for any of a number of reasons that 
may not be able to be alleviated m a tunely fashion so that the user can be registered at 
this thh-d party web site in a short amount of time. Accordmgly, step 684 is encountered 
wherein a message is transmitted to the user's WWW client node 108 indicating that 
regisfrar cannot currently register the user at the requested third party web site 116. 
Fxirther, note that if in step 680 it is determined that too many attempts have been made 
to generate acceptable registration information for the third party web site, then step 684 
is also encovmtered. 

The flowchart of Figs. 6 A and 6B is rq)resentative of the processing variations 
within the scope of the present invention for supplying a third party web site with 
registration information. For instance, those skilled in the art will appreciate that steps 
624 and 660 may have a timer associated wifli them whereby if there is no response from 
the third party web site within a predetennined time period, then a defauh response is 
provided by a registrar application 128 so tiiat one of the steps 684 or 636 is performed 
as part of the processing when such a timer expires and subsequent steps in the flowchart 
are performed. Additionally, other stqjs may be mserted, for example, on the negative 
branch from step 676 wherein these additional st^s attempt to address other anomalies 
indicated in the acceptance response received in step 660. For example, if the thhd party 
web site 116 requests additional user information than what was provided in step 648, 



then if this additional information is in the user registration information database 144 and 
the user has indicated that it is permissible to disseminate this information, then the 
additional information may be transmitted to the present third party web site 116. Also, 
in such a case, the transmittal of this additional information is recorded in the registrar 
5 access log database 152. 

Referring now to Fig. 7, wherein the flowchart for a program is provided for 
supplying, from the user registration information database 144, a requesting third party 
web site 116 with registration information related to a particular user. Accordingly, in 
step 704 of Fig. 7, if the registrar web site 100 has not been previously supplied with an 

1 0 indication as to what type of information is required by the requesting third party web 
site, then a registrar application 128 constructs such a request to be transmitted to the 
requesting third party web site and subsequently the appHcation may wait for a response 
from this third party web site. Following step 704, in st^ 708 it is assiuned that the 
registrar web site 100 has been provided with an indication or specification as to what 

1 5 information the requesting third party web site desires. Thus, the registrar application 
128 performing step 704 may now determine what registration information is to be 
transmitted to this third party web site. Note that at least in one embodimait of step 708, 
the user registration information requested may require vaKdation according to the 
following criteria: 

2 0 (1.1) The type and amount of registration information for a user that the user has 
indicated is available to be transmitted to a requesting third party web site. 
(1.2) The type and amount of information the requesting third party web site 116 has 
contracted with the registrar web site 100 for transmitting regarding a particular 
user or category of users. 



(1.3) The registration information available in the user registration information 
database 144. 

Thus, as discussed with respect to step 604 of Fig. 6 A, either basic, expanded, custom or 
proprietary registration information related to a user is transmitted to the requesting third 
5 party web site in step 736. 

Fig. 8 presents a flowchart for storing, in the user registration information 
database 144, a user's ID and/or password for a third party web site 1 16 to which the user 
is registered using registrar. More precisely, the user ID and/or password for such a third 
party web site is stored via the steps of Fig. 8 if this information is different from the 

1 0 user's registrar user ID and/or password. That is, it is beUeved that for many third party 
web sites 1 16, the registrar user ID and password for users registered at the registrar web 
site 100 will be identical to the user's user ID and password at third party web sites. Note 
that there are significant advantages to third party web sites 116 using, for each registered 
user, the user's registrar user ID and password (or, some other user ID and password in 

1 5 common with other third party web sit^ to which the user is registered). For instance, 
a user is required to remember fewer user IDs and passwords associated with web sites 
and the web sites providing this convenience may have a higher volume of users 
accessing the web site due to the greater ease of access. 

Regarding the steps of Fig. 8, in step 800 a determination is made as to whether 

20 the user has been provided with a user ID (optionally password) for the third party web 
site 116 (to which the user is attempting to register) that is dififerent from the user's 
registrar user ID and/or password. If not, then there is nothing additional to store at the 
registrar web site 100 and the flowchart ends. Alternatively, if the decision of step 800 
results in a positive answer, then step 804 is performed wherein the user's specific user 



ED and optionally password for this third party web site is stored with other user 
registration information in the user registration information database 144. Note the 
following advantages accrue by storing user registration information at the registrar web 
site: (a) each user has the convenience of off-site storage backup for each such third party 
web site to which the user is registered and (b) depending on the registration process at 
the third party web site, it may be expedient for such a web site (at least temporarily) to 
automatically contact the registrar web site 100 for retrieving, for example, the user's 
third party web site specific user ID upon subsequent user accesses to the third party web 
site. 

Following step 804, in step 808 a determination is made as to whether the third 
party web site has indicated that it will initiate requests as in (b) immediately above. If 
so, then no further processing needs to be accomphshed here in that the user may enter 
his/her user registrar web site 100 user ID (and optionally password) when accessing the 
third party web site. Alternatively, if stqp 808 yields a negative answer then step 812 is 
performed wherein the registrar web site 100 sends a message to the user at the user's 
WWW cUent node 108 providing the usar with the ID (and optionally password) for the 
third party web site. 

In an alternative embodiment of the present invention, a registrar registration 
module 156 may be provided at the user's WWW client node 108. This module (whether 
incorporated into the WWW browso: 120 or external to the browser and communicating 
with the browser through, for example, a browser 120 port) may store locally at the client 
node 108 registration information for accessing third party web sites 1 16 to which the 
user has registered using the present invention. In Figs. 9-13, flowcharts are provided for 



programs illustrating the processing of this alternative embodiment of the present 
invention. 

In Fig. 9, a flowchart is presented of the program for registering at a third party 
web site 1 16 when the module 156 is installed on the user's client node 108. 

Describing now the steps of Fig. 9, in step 904 the user sends a request to access 
a third party web site 116 via the user's WWW browser 120. Subsequently, upon 
receiving the request, the accessed third party web site 116 responds with a home page 
havmg a registration fill-out form (step 908). Assuming that the registration fill-out form 
allows the user to indicate that user registration information may be obtained locally at 
the client node 108, in step 912 the user indicates on the fill-out form that he/she desires 
to register at the third party web site and that his/her registration information can be 
retrieved using the registrar registration module 156 residing on the user's chent node 
1 08. Furflier note that the user may be required to activate or alert the module 1 56 so that 
this module can supply the ^propriate usct registration information to be commimicated 
to the third party web site 1 16. Also note that the home page firom the third party web 
site 116 may indicate the type of information required to register the user and this 
information may be used either manually or automatically for determining the user 
registration information stored on the user's chent node 108 that will be transmitted to the 
third party web site. Subsequently, in stq) 916 the user specifies that the registration fill- 
out form is to be submitted to the third party web site. Accordingly, the WWW browser 
120 communicates with the registrar registration module 156 to supply the registration 
information to the third party web site. That is, the processing performed here includes 
the steps of Fig. 10 which are described herein below. Subsequently, in step 920 a 
message is sent firom the registration module 156 to the registrar web site 100 indicating 



that the user has registered at the third party web site and additionally supplying the 
registrar web site 100 with any user ID and password specific to the third party web site. 
Note that by sending this information as well as, for example, a copy of substantially all 
of the iiser's registration information stored locally to the registrar web site 100, the user 
is provided with an automatic off-site backup of his/her registration information. 
Additionally, the user may be provided with other advantages by providing his/her user 
registration information to the registrar web site 100. In particular, the registrar web site 
100 may enrich the user's registration information with pubhcly available information on 
the user and alert the user to discrepancies between the user information and various 
publicly available records on the user. 

Referring now to the flowchart of Fig. 10, this flowchart describes the steps 
performed when supplying a third party web site 116 with registration information 
retained by the registrar registration module 156 on the user's node. In step 1004, the 
steps of the flowchart of Fig. 7 are performed for reeving the registration information 
requested by fee third party web site. Subsequently, in step 1 008 the registrar registration 
module 156 packages the accessed registration information for the third party web site 
togedier with the user's registrar ED (and optionally password) for transmittal to the third 
party web site. Subsequently, in step 1016 the registration information packaged together 
in step 1008 is encrypted so that in step 1020 this encrypted information may be sent 
securely to the third party web site via the World Wide Web 104. Following this, in step 
1024 the module 156 logs an entry into a local log on the client node 108 indicating what 
registration information was sent to the third party web site. Subsequently, in step 1 028 
a process may be instantiated to wait for an acceptance response fi-om the third party web 



site so that when such a response is obtained it may be logged locally at the cUent node 
108 in step 1032. 

In one embodiment of the present invention the user may configure the registrar 
registration module 156 to log all activities with third party web sites 116 and provide the 
records of this log to the registrar web site 100. This allows the registrar web site 100 or 
personnel that maintain the registrar web site 100 to analyze user activities on the World 
Wide Web 104. Such analysis may be usefiil to both registrar users and third party web 
site personnel in that, given a user's World Wide Web 104 activity, the registrar web site 
1 00 may suggest additional third party web sites 1 16 of which the user may not be aware. 
Further, by analyzing the user access logs of registrar users, the registrar web site 100 
may provide statistics to the third party web sites 1 16 as to the number and types of users 
accessing their respective web sites. 

Figs. IIA and IIB present a flowchart for the stq)s performed by the present 
invention when the user changes his/her registrar registration information. That is, the 
flowchart of Figs. 1 1 encompasses both the architecture or embodiment of the present 
invention wherein the user's registration information is stored substantially only at the 
registrar web site 100, and also the architecture or embodiment whetein the user's 
registrar information is also stored at the user's clirait node 108. Accordmgly, in step 
1 104 a determination is made as to where the user's registration information is stored. 
Note that this step 1104 is vinlikely to be expUcitly performed by either the present 
invention or flie user. Instead, the embodiment of the present invention determines which 
of the paths firom this step to follow (i.e., if module 156 exists, then the "USER NODE" 
branch is followed; otherwise, the "REGISTRAR WEB SITE ONLY" branch is 
followed). Accordingly, assuming that the present invention is embodied such that the 
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user's registration information is stored at the web site 100 only, then step 1108 is 
encountered wherein the user accesses the registrar web site 100 from his/her WWW 
client node 108 by entering his/her user ID and optionally password. Subsequently, in 
step 1112 the registrar web site 100 responds with a web page having a number of 
options related to the user's registration information and registrar web site 100 processing 
of this information. Note that such options include a request by the user to modify the 
user's registration information stored at the registrar web site. Additionally, other options 
may be also provided to the user including: (a) an option for requesting to be no longer 
affiliated with the registrar web site 100 and have all the user's registration information 
deleted; (b) an option for requesting to examine all information regarding the user stored 
at the registrar web site 100, including all information the registrar web site has obtained 
from publicly available sources; (c) a request for procedures and/or addresses to contact 
publicly available databases that registrar has accessed obtaining incorrect user 
information; and (d) third party web sites 116 that are providing information for a limited 
period of time and for which the user may be interested. Following step 1 1 12, in step 
1116 the user enters new information uito an appropriate fiU-out form received at the 
user's WWW client node 108 from the registrar web site 100. Note that this form is 
likely to be in a page differait from the page of options described in step 1112. That is, 
upon submission of the page of options, the registrar web site 100 responds with a new 
page(s) having fill-out forms with the presently stored user regisfration information 
presented in the forms so that the user may change any of the fields on this page(s). 

Note that in at least one embodiment of the present invention, the user is allowed 
to change his/her registrar user ID and/or password. However, it may be the case that 
when a user changes his/her registrar user ED, that the new requested user ID has already 
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been assigned to another registrar user. Thus, the registrar web site 100 may respond 
with a request for ftirther information (such as a request for a different user ID from the 
user) wherein when the user submits the additional information, the registrar web site 100 
again checks to determine if the user is uniquely identifiable. Note that the loop of steps 
1 120 and 1 124 are provided to represent the iterative process described here of changing 
the user's user ID. Further note that in some embodiments of the present invention, the 
registrar web site 100 may respond with alternative variations for a new user ID so that 
the user is not left to guess at a registrar user ID that is acceptable for uniquely identifying 
the user. 

Returning now to step 1 104, if the user's registration information is stored locally 
at the user's cUent node 108, then step 1128 is performed instead of the steps 1108-1 124. 
However, for simphcity, a discussion of the processing performed in step 1128 is not 
described in detail here. Instead, a detailed discussion of this step is provided by Figs. 
12 and the discussion of Figs. 12 hereinbelow for changing the registration information 
at the user's cUent node 108 and for transmitting the changes to the registrar web site 100. 

Regardless of the branch of processing taken from stqs 1 104, eventually step 1 1 32 
and the subsequent steps of Fig. 1 IB are encoimtered wherein the present invention 
updates or alerts third party web sites having previously received user registration 
information that this information may be outdated. Thus, the stq>s 1132-1140 are 
performed so that the registration information provided to such third party web sites via 
the present invention is consistent with tiie newly suppUed user registration information. 
However, in at least one embodiment of the present invention, prior to providing any 
newly entered user registration information to the third party web sites, such information 
may be compared or correlated wilh pubUcly available information regarding tiie user that 



is, for example, accessible via certain third party web sites 1 16. Further, the user may 
request his/her newly entered registration information by supplied to only selected web 
sites to which the user is registered, or alternatively, the user may request that the newly 
entered registration information be supplied to all web sites to which the user is 
registered. 

Fig. 12 presents a flowchart of the steps performed when the registrar registration 
module 156 is provided at the cUent node 108 and the user enters registration information 
into this module. Note that the steps of this flowchart may be performed when the user 
is entering registration information for registering the user with registrar, or when 
modifying registration information already suppHed to registrar. Accordingly, in step 
1204 the user requests activation of the registrar registration module 156 on the user's 
client node 108 for entering information that will subsequently be used for registering 
substantially automatically cooperating at third party web sites 116 requested by the user. 
Subsequently, in stqp 1208 the registrar registration module 156 on the user's client node 
108 presents the user with one or more fill-out forms for the user to provide new 
registration information. Following this, in step 1212 a determination is made as to 
whether the user requests to obtain a registrar user ID. If so, then in §tep 1216 the 
program corresponding to the flowchart of Fig. 13 is performed to provide the user with 
a valid registrar user ID and optionally password. Subsequently, in step 1220 a 
determination is made as to whether the program of Fig. 1 3 returns a valid registrar user 
ID. If so, then step 1224 is performed wherein the new user's registrar ID is stored on the 
user's node 108 for a subsequent transmittal to a third party web site during a registration 
process at a third party web site that accepts the registrar user ID as the web site's ID. 
Subsequently, regardless of the path taken from step 1220, step 1228 is encountered 



wherein a determination is made as to whether the user desires to enter further user 
registration information. 

If the user desires to enter further information, then step 1212 is again 
encountered and a determination is made once again as to whether the user requests to 
obtain a registrar user ID. However, it is important to note that the steps provided in this 
flowchart are only an indication of the processing provided by the registrar registration 
module 156 and the user's browser. In particular, since the user interfaces typically used 
by World Wide Web browsers allow a user to select the fill-out form fields to modify, the 
positive branch firom step 12 1 2 is taken only when the user enters information in a fill-out 
form field indicating that a registrar user ID is requested. Similarly, the negative branch 
firom step 1212 is taken whenever user information is entered into other fill-out form 
fields unrelated to obtaining a registrar user ED. 

Accordingly, if the user desires to alter other information than that required to 
obtain a registrar user ID, then from step 1212, step 1232 is encountered wherein the 
registrar registration module 156 explicitly requests the user's registrar registration user 
ID (and optionally password). Subsequently, in step 1236, assuming the user enters a 
registrar user ID, a determination is made as to whether the registrar user ID is valid. 
Note that this determiaation is initially made locally at the user's clioit node 108 without 
contacting the registrar web site 100. However, in one embodiment of the present 
invention, it is an option that if the registrar usa: ID entered is not found in the client node 
108, then the registrar registration module 156 may inquire of the user as to whether 
he/she desires the registrar web site 100 to be interrogated for the registrar user ID and 
password and, if found, download the user's registration information to the user's client 
node 108. If no valid registrar user ID is determmed in step 1236, then the program ends 
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in step 1240. Alternatively, if a valid registrar user ID is obtained, then in step 1244 a 
determination is made as to whether the user requests to exit the present program and 
thereby stop supplying registration information. Note that this step is similar to step 1212 
in that if the user continues to enter registration information in fill-out form fields, then 
the negative branch from this step is followed and, altematively, if the user, for example, 
activates an exit button on the user interface, then the positive branch from step 1244 will 
be followed. Accordingly, if the negative branch is followed, then in step 1248 the 
program of Fig. 3 is performed for obtaining new user registration information and, 
subsequently, step 1212 is encountered (or, more precisely, the user interface is provided 
that allows the user to request a regisfrar user ID). 

Altematively, if the positive branch is taken from step 1244, then step 1252 is 
encountered wherein the registrar registration module 156 transmits (or schedules the 
transmission of) any newly entered user registration information that the user desires to 
be transmitted to the registrar web site 100 for backup storage. Thus, in one embodiment 
of the present invention, the step 1252 provides the user with the option to discard the 
registration information provided in step 1248 above instead of fransmitting this 
information to the registrar web site 100. 

In Fig. 13, a flowchart is presented of the program for obtaining a registrar user 
ID and optionally password for the embodiment of the present invention wherein the 
registrar registration module 156 retams the user's registrar user ID (and optionally 
password) for automatically providing to third party wd? sites at which the user requests 
registration using the present invention. Accordingly, in step 1308 the registrar 
registration module 156 requests tiie user to select a registrar user ID and optionally a 
password that can be used to access the user's registration information at both the user's 



client node 108 and at the registrar web site 100. Assuming that the user enters a user ID 
and optionally password in step 1308, in step 1312 the registrar registration module 156 
transmits the user selected ID and optionally password to the registrar web site 100. 
Subsequently, m step 1316 a determination is made by the registrar application 128 as to 
whether the user's selected user ID and optionally password are acceptable to the registrar 
web site. That is, a registrar application 128 accesses the user registration mformation 
database 144 to determine if the selected user ID is sufficiently unique. Note that other 
steps may be performed between steps 1308 and 1312. For example, the syntax for user 
IDs and optionally passwords may be checked at the module 156 prior to transmitting the 
user's selected registration information to the re^strar web site 100. 

Continuing with step 13 16, a determination is made at the registrar web site 100 
as to whether the user's selected user ID and optionally password are acceptable to 
registrar. If so, then in step 1320 a registration ^plication 128 stores the user's ED and 
optionally password in the user registration information database 144. Note that since 
it is imlikely that any ftuiher information related to the present user is stored at the 
registrar web site, the process of storing the user's user ID and optionally password 
includes creating a new record in the database 144 and maridng all remmning fields 
related to registration information for this user to indicate that these fields are as yet not 
valid. Following this, in step 1324 a registrar application 128 transmits a message to the 
user's WWW browser 120 indicating that the user's selected user ID and optionally 
password is acceptable to registrar. 

Alternatively, if the negative path is taken firom step 1316, then step 1336 is 
encountered wherein a registrar application 128 attempts to generate an acceptable user 
ID and optionally password as a substitute for the user's proposed user ED (and optionally 
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password). Note that in generating alternative registration information, the registrar 
application 128 may use the user suppKed information as the basis or "seed" for 
generating an acceptable user ID (and optionally password) to be transmitted back to the 
user. Accordingly, in step 1340, once the user is presented with the newly generated 
registration information on the user's client node 108, the registrar registration module 
156 provides the user with the option to accept or reject the generated information. If the 
user accepts the generated registration information, then the flowchart ends. 
Alternatively, if the user rejects this information, then in step 1348 a further 
determination is made by the module 1 56 as to whether the user enters a new user ID (and 
optionally password) as an altemative to the generated registration information. If such 
new user registration information is provided, then step 1312 and steps thereafter are 
again performed in attempting to provide a registrar user ID (and optionally password) 
to the user. Alternatively, if the user indicates in step 1348 that no further proposed 
candidates for a user ID (and optionaUy password) will be forthcoming, then the 
flowchart ends without an acceptable registrar user ID being obtained. 

The foregoing discussion of the invention has been presented for purposes of 
illustration and description. Further, the description is not intended to hmif the invention 
to the form disclosed herein. Subsequently, variation and modification commensurate 
with the above teachings, within the skill and knowledge of the relevant art, are within 
the scope of the present invention. The embodiments described hereinabove are further 
intended to explain the best mode presently known of practicing the invention and to 
enable others skilled in the art to utilize the invention as such, or in other embodiments, 
and with the various modifications required by then" particular application or uses of the 



invention. It is intended that the appended claims be construed to include alternative 
embodiments to the extent permitted by the prior art. 
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